User blog:Technobliterator/Building Better Boxes: Organizing Your Data
Hey! I'm Technobliterator from , here with another topic on how to make your Portable Infoboxes better. When you're making an article as a wiki editor, naturally your aim is to list all the available and relevant information about the subject. But an equally important aim is to display that information on pages in a way that's convenient and elegant for readers, whether they're just passing by to quickly check a stat value, or whether they want an in-depth description. Infoboxes are an excellent way of conveying information to readers immediately, but they're by no means the be-all end-all. Bite sized boxes Infoboxes are useful for displaying quick facts, whether they’re for users who just want to check when Rey was born, or if they want to know where they can fight Ruby Weapon. In a box that’s easily accessible and readable to users (not taking up too much space on a desktop screen while being immediately available on a mobile one), an editor can very easily list many summarised facts from which a reader would benefit. At the same time, infoboxes also have a limited width. This means that the facts contained in infoboxes are generally just a couple words, bullet points, or (at most) a sentence. A table in an infobox often doesn’t span more than six columns (at maximum), and this limited space means that they may be unsuitable for larger amounts of data, as they may not provide such data legibly. Statistical values that can be absorbed in bite-sized chunks are often great on an infobox, as well as small details about the subject; that’s generally where the line is drawn. Beyond this, users will struggle to fit a significant amount of data in them without severely lengthening the infobox or producing designs that they may struggle to read. They can choose to try and fit this data into collapsibles, mouse-overs, or many other methods of fitting the information in a small space. At that point, it’s often better to simply stop and consider why you’re being forced to do that. Is it because infoboxes are too inherently restrictive, or is it because the data you’re including could belong elsewhere? Let's table that... MediaWiki contains very simplified HTML table syntax, which is helpful because tables are an invaluable tool in displaying data. Through CSS, these tables can be half the width of the screen, or they can be the full width. They can span extremely long vertical space, or they can simply be a footnote. They’re a dynamic and flexible form of information. But they, too, are not a complete panacea to all problems. Sometimes that data is more easily accessed in an infobox than through scrolling down to read a table. Otherwise, it’s a table containing information that could be rendered redundant by prose. Tables generally shouldn’t be used to summarise facts, and they’re not really useful for instant facts; they are very useful for the readers who need to know more than what they can find in a quick summary at the beginning of the content. If there is a lot of data and squeezing it into the small space of an infobox is too difficult, it’s often by far the best choice to instead move large amounts of that data into tables instead. The design choice may not be easy for you (the editor), but for the readers the information will be more accessible and available. Drawing the middle line This case is often not as clear cut. Sometimes there may be pages where all the data contained is absorbed in relatively bite-sized chunks and doesn’t span too many rows or columns; as such, an infobox is a great choice to fit it right next to the prose of the article. Other times, the same type of page may contain relatively similar data, but suddenly a lot more is needed. To fit the same amount of data in, multiple infoboxes would be needed. The best practice to follow is that only a single infobox should be used per page (with some exceptions). One infobox should contain one summary of the data, or one list of data. If multiple infoboxes are required, or several collapsibles, tabbers, mouse-overs among other things are required to contain the data in a small space, that’s when it’s time to move that data to a table. If two pages of the same type contain very different amounts of content, then instead of trying to stretch the infobox that works great on one page to work well on another, it’s often much better to create a separate template for the other page. Whether this means creating a simplified version of a bigger infobox and accompanying it with a table, or whether it means just dropping bigger infoboxes for this type of page in favour of one consistent design with tabled templates for that data across all pages, it generally isn’t an issue. If your data is easily accessible to readers, they will find it. Links to lower portions of the page among other things to make your design painfully obvious to readers may also be necessary if absolute consistency is not possible, otherwise, the more consistent and familiar your design is to readers, the better. In fact, you can easily style these tables to have a similar appearance to your infoboxes by using similar, or even identical, CSS. Ultimate goals of organizing data Maybe you’re frustrated that a feature you had on your old infoboxes simply doesn’t work on your new ones, or you’re frustrated that including multiple infoboxes on your page is causing it to slow down. But that’s not always the case. While it may often be a valid concern you have about a missing feature that makes sense on an infobox (being unable to style specific cells, not being able to include horizontal rows within collapsible groups), when it doesn’t make sense, then it’s up to you, the designer, to make it work better. The ultimate goal and the primary aim of your wiki is to serve its readers in the best possible way. And making your page be foolproof, be portable, and having your information easily accessible is how you’re going to reach this goal. Understanding when and where to include data of certain types is the first step towards a design that works best. So really, you need to think about where and how your data should be organized. If you get it right, not only will you be satisfied with your design, your editors will be satisfied with continuing it, and your readers will be very satisfied reading it, and they’ll want to come back. Most importantly, at no point should you feel as if you are being forced to choose between harming desktop users or harming mobile users - if you strike the perfect balance, if you define your design decisions in the best way possible, you will be benefiting both. Further reading You don’t really have to take our word for it. A design may make perfect sense to you, the designer, but not much to the readers, and it sometimes seems impossible to gauge what exactly their reaction to your content is. Luckily, this topic has been well researched by many web designers. But ease of use is almost certainly the most important goal of any design, and so content that can be read fluidly by people regardless of what device they’re using, what condition they may have, or how much information they need at any given time. Below are some articles written by prominent web designers about ease of use (credit to Dessamator for these links): *http://www.nngroup.com/articles/how-little-do-users-read/ *http://www.nngroup.com/articles/how-users-read-on-the-web/ *http://www.nngroup.com/articles/website-response-times/ *https://phabricator.wikimedia.org/T21262 Category:Blog posts